-
Notifications
You must be signed in to change notification settings - Fork 1.2k
.add/files.add http-api endpoint #323
Conversation
Do you have some failing tests? (Travis only seems to be complaining about standard) How can I repro? |
@noffle thanks for taking a look! I've added the http tests with daemon on that should throw an error. I have just been manually trying to add a file with the go/js-ipfs daemons running. |
Hey @nginnever, I noticed a couple of things:
|
My thoughts exactly on the inconsistency in
Ahh good catch, still some old tests slipping in before the changes to return type. |
@noffle I've created a branch on js-ipfs-api that updates Though the issue is still as mentioned above that sometimes the response from If you run the tests now you will see this issue throw an error. Seems like the core gets the proper data from the dagservice here. but not when returned here After some investigating I found that this line in the object resource is the culprit. Removing the toString seems to fix. This PR is now waiting on |
@nginnever how is PR coming along? |
Once #420 is merged, could you rebase this PR @nginnever ? |
beep boop, #420 is merged :) |
beep boop, needing this one for #432 :) |
@victorbjelkholm got #323 (comment) released |
Upgrade and merge conflict resolution happening here: #469 |
Ok, so @victorbjelkholm finished up the integration and got all tests passing for get, cat and add 👏👏👏👏. Thank you @nginnever and @noffle for having kicked off all of this work 🌟 👌🏽 Now it is all about the big rebase (because js-ipfs codebase changed with the migration to pull-streams). This is happening here: #469 by @dignifiedquire Closing this PR, let's track the rest on the rebase PR (which is already pointing to master) #469 |
Upgrade the files branch (#323) to work with pull-streams
This continues PR
Currently the
files add
http resource is failing when the js-ipfs daemon is running do to this line in js-ipfs-api.https://github.com/ipfs/js-ipfs-api/blob/master/src/get-dagnode.js#L30
@noffle might have some ideas on this. It seems that the js-ipfs-api
object/data
responses don't match when coming from js-ipfs and go-ipfs daemons.